1с согласование заявки расходование средств. Документ "заявка на платеж". Загрузка и выгрузка платежных документов в клиент-банк

"Миллионное дело приходится начинать при ощутимой нехватке денежных знаков".

И. Ильф и Е. Петров

Операционное планирование движения денежных средств или как построить систему контроля расходования денежных средств

Введение

Данная статья посвящена операционному планированию движения денежных средств (далее по тексту «ДС»), и будут раскрыты следующие аспекты этой деятельности:

1. роль операционного планирования ДС в жизни компании;
2. подсистема операционного планирования ДС в типовой конфигурации «1С:Управление производственным предприятием ред. 1.3 (релиз 1.3.32.1)» (далее по тексту УПП);
3. особенности и ошибки типовой подсистемы УПП;
4. практический опыт внедрения подсистемы операционного планирования ДС;
5. возможные варианты доработок, исправления ошибок типовой подсистемы УПП.

1 Роль операционного планирования ДС в жизни компании

Мечта любого CFO (Chief Financial Officer - финансовый директор) - отсутствие «кассовых разрывов» (кассовый разрыв - недостаток денежных средств для исполнения текущих обязательств компании в определенный момент времени) в его компании, и эта мечта стала еще более навязчивой в период кризиса. Деньги - движущая сила компании, и их отсутствие, даже на короткий период, может привести к «тяжелым болезням» или даже «гибели» компании. Причиной «кассовых разрывов» является несовпадение сроков поступления денежных средств и их расходования, что может быть вызвано рядом объективных причин, например: сезонными особенностями сферы деятельности компании. В качестве примера можно привести сельскохозяйственные (растениеводческие) компании, которые несут основные затраты зимой и весной, а основную долю выручки получают осенью. При возникновении «кассового разрыва» компании приходится прибегать к различным мерам по их устранению, например: привлечение банковских кредитов, займов, срочная продажа ликвидных активов и т.д. Несмотря на принятые меры, указанная ситуация так или иначе пагубно отразится на благосостоянии компании. Таким образом, разработка системы планирования, исполнения и контроля движения денежных средств является одной из главных задач финансового директора компании.

2 Подсистема операционного планирования ДС в типовой конфигурации «1С:Управление производственным предприятием ред. 1.3» (далее по тексту УПП)

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

1. Документ «Планируемое поступление денежных средств »: этим документом отражается плановое поступление ДС. В документе указывается конкретный контрагент, договор, статья движения денежных средств и т.д. В документе есть специальный признак «Включать в платежный календарь», если его не установить, то данные не будут попадать в регистр «Расчеты с контрагентами» и, как следствие, в отчет «Платежный календарь» и другие отчеты.

Особенность 1: Если после проведения этого документа посмотреть отчет «Ведомость по расчетам с контрагентами», то в нем увидим приход на сумму документа, что и должно получиться в результате. И в этом случае важно при вводе документа оплаты (п/п или ПКО) подвязать документ планирования поступления ДС, иначе мы увидим задвоение сумм прихода в отчете. Также в случае отсутствия связи документов в платежном календаре будут представлены неверные данные. Ошибиться легко, например, если указать в документе планирования форму оплаты «Наличные», а оплату провести безналичными, то в этом случае не возможно будет указать связь документов и, как следствие, возникнет задвоение. Даже если вами будет использовать механизм «Ввести на основании» для отражения факта оплаты, и в структуре подчиненности будет видна связь двух документов, это не означает, что по регистрам все пройдет правильно.

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

Особенность 2: Если заявка не утверждена, то она все равно попадает в отчет «Платежный календарь» при установленном флаге «Включать в платежный календарь». Дискуссию на тему «Оправдано это или нет» оставим за рамками статьи. При вводе оплаты легко допустить ошибки, описанные в разделе «Особенность 1».

1. Документ «Закрытие планируемых поступлений »: указанный документ предназначен для закрытия документов «Планируемое поступление ДС», т.е. планируемая сумма (часть суммы) поступления ДС «удаляется».

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

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

Особенность 4: аналогичные нюансы описаны в «Особенность 3».

1. Отчет «Платежный календарь »: данный отчет показывает предстоящие расходы ДС и поступления, что позволяет увидеть «кассовые разрывы».

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

1. Отчет «Анализ доступности ДС »: этот отчет показывает остаток ДС в компании, зарезервированные по заявкам ДС, а так же ДС на списание и получение.
2. Отчет «Заявки на расходование средств ». Если верить справке УПП, то этот отчет называется «Неоплаченные входящие платежи» и «предназначен для получения информации по входящим платежам, которые зарегистрированы в системе, но по которым не выполнено ни одно из необходимых действий: отражение в оперативном учете или фактическое движение денежных средств (оплата)». J Забавно! За «настоящей» справкой идем в конфигуратор и видим описание: «предназначен для анализа исполнения заявок на расходование средств за определенный период времени. В колонке «Приход» отображаются суммы по оформленным заявкам, в колонке «Расход» - исполнение заявок за период (оформление на основании заявок платежных документов или их закрытие). Остатки на начало и конец периода показывают неисполненные суммы по заявкам.»
3. Отчет «Планируемые поступления ДС ». Если поверить справке, то это все тот же отчет «Неоплаченные входящие платежи» J . В конфигураторе: «предназначен для анализа исполнения планов по поступлению денежных средств, оформленных соответствующими документами за определенный период времени. В колонке «Приход» отображаются суммы запланированных поступлений, в колонке «Расход» - исполнение планов по поступлению денежных средств за определенный период (оформление входящих платежных документов на основании документов планирования поступления денежных средств).»
4. Регистр сведений « Настройки согласования заявок на расходование ДС »: регистр предназначен для «включения» использования механизма согласования заявок по конкретной организации и периоду.
5. Справочник «Маршруты согласования заявок »: в данном справочнике прописываются маршруты согласования заявок на расходование ДС.
6. Регистр сведений «Настройки маршрутов согласования заявок » прописывает маршрут согласования заявки, причем в типовом функционале он зависит лишь от подразделения (ЦФО - центра финансовой ответственности) заявки.
7. Обработка «Согласование заявок» : в этой обработке происходит согласование заявок.
8. Дополнительное право «Разрешить проведение платежа без заявки » позволяет проведение платежа без утвержденной заявки.

Особенность 5: Ограничение права не срабатывает (легко обходится) в случае если:

А) платежный документ проводится не оперативно;

Б) в РКО не установлен признак «Отразить в опер.учет»;

В) платежный ордер и РКО с видом операции «Выплата заработной платы». Это ошибка УПП: в коде идет проверка по неверной табличной части документа.

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

3 Особенности и ошибки типовой подсистемы УПП

Особенности и ошибки типовой подсистемы рассмотрим на конкретном примере.

Первоначальные данные (условия задачи):

А) вводим новую организацию «ТРГ» в демобазу УПП;

Б) вводим начальные остатки ДС (на 01.11.2012 года ): 1 млн.раб. на расчетном счете и 50 тыс.руб. в кассе;

В) заводим новых пользователей «Менеджер по закупкам» (не устанавливаем дополнительное право «Разрешить проведение платежа без заявки» ) и «Менеджер по продажам».

1. Менеджер по продажам планирует в текущем месяце продать «товар 1» (оплата планируется по безналичному расчету) на сумму 600 000 рублей и вводит документ «Планируемое поступление ДС».

Важно: если не устанавливать признак «Включать в платежный календарь», то планируемое поступление ДС не будет попадать в отчет «Платежный календарь», «Ведомость по расчетам с контрагентами». В нашем примере мы её установим.

Посмотрим в отчет «Платежный календарь»:

Обратите внимание на данные, которые покажет отчет, если период установить с 01.11.12 (с момента ввода остатков):

Важно эту особенность помнить!

Также обратите внимание на то, что отчет не показывает (это ошибка отчета) остатки по наличным в отдельном разрезе:

1. Как и было запланировано, продажа состоялась, но покупатель первую поставку оплатил по безналу , а вторую поставку оплатил наличными . Вводим документы реализации на сумму 400 000 и 200 000 рублей, далее через механизм «Ввести на основании» введем п/п на сумму 400 000 и ПКО на сумму 200 000 рублей. Давайте проанализируем отчеты:
   1. Отчет «Платежный календарь» сформируем с 02.11.2012 по 31.12.2012, получаем следующий результат:

Осталась запланированная сумма в 200 000, хотя оплата прошла. Это произошло из-за того, что мы планировали всю оплату по безналичному расчету, а 200 тыс. получили наличными и, соответственно, заявку не смогли «подтянуть» к кассовому документу, при этом «не помогло» даже то, что все документы мы вводили используя механизм «ввести на основании», и в структуре подчинённости мы видим цепочку:

Удалим ПКО и сделаем п/п на 200 тыс., однако не установим признак «Оплачено». Таким образом, мы увидим следующую картину в платежном календаре:

1. Запланируем расход ДС на сумму 500 000 для оплаты поставщикам. Введем заявку на расходование ДС:

Платежный календарь будет выглядеть следующим образом:

Обратите внимание, что расход запланирован на 09.12.12, хотя дата заявки 08.12.12, это правильно, т.к. в поле «дата расхода» мы указали 09 число.

1. Утвердим заявку. Утверждение происходит из обработки «Согласование заявок», также механизм согласования доступен через Web интерфейс. В обработке согласования есть очень удобная и полезная функция настройки отчетов:

Предварительно отчет разрабатывается и сохраняется в разделе «Произвольные отчеты» (Сервис->Произвольные отчеты»), далее он используется для вывода нужной информации при согласовании заявок. Используя этот функционал, можно настроить отображение остатков на расчетных счетах с учетом оплаты утверждаемых заявок, также можно показать соответствие заявки бюджету и т.д. Возможность согласования через Web интерфейс позволяет руководителю, находясь не на рабочем месте, контролировать платежи.

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

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

Из-за этой ошибки, как и в отчете «Платежный календарь», появляются «чудеса»:

Также не происходит контроль в РКО при снятом флаге «Отразить в опер.учет».

Не происходит контроль также и в Платежном поручении, в и РКО с видом операции «Выплата заработной платы», что является ошибкой типовой УПП.

4 Практический опыт внедрения подсистемы операционного планирования движения ДС

Теперь рассмотрим практический опыт внедрения данной подсистемы в крупном агрохолдинге (назовем его «Агро»), при этом уделим внимание лишь расходной части операционного планирования, т.к. она самая интересная и животрепещущая, ведь на расходы мы повлиять можем, а вот на доходы повлиять не так-то просто.

Внедрение подсистемы операционного планирования движения ДС в «Агро» началось вместе с комплексной автоматизацией учета на базе УПП 1.3. Ранее в холдинге велся учет в 8 различных конфигурациях (более 5 удаленных офисов в 4 областях нашей страны), а операционное планирование движения ДС велось в Excel. В конце месяца дочерние компании отправляли в управляющую компанию (далее по тексту УК) как планы по расходованию ДС, так и планы по поступлению ДС. Сотрудники казначейства УК сверяли присланные планы с бюджетом, далее отправляли на согласование руководителям по направлениям, руководители по направлениям корректировали и согласовывали планы движения ДС. Затем казначейство УК консолидировало планы, поступившие от руководителей по направлениям, и отправляло итоговый план генеральному директору на утверждение. Утвержденный план рассылался обратно в дочерние компании, и в течение месяца сотрудники казначейства УК сверяли движение ДС с утвержденным планом, т.е. контролировали его исполнение.

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

Результат, полученный от внедрения данной подсистемы:

1. усилен контроль расходования ДС в компаниях холдинга;
2. увеличилась скорость подготовки планов движения ДС;
3. исполнение плана движения ДС стало более «прозрачным»;
4. «кассовых разрывов» удалось избежать.

Хочется отметить, что после внедрения УПП в компаниях холдинга (более 120 пользователей работают в on-line режиме используя Web клиента или удаленное подключение через RemoteAPP) и подсистемы операционного планирования ДС в частности, тема: «согласована заявка на расходование ДС или нет?» стала одной из самых животрепещущих в компании. На поверхность «вылезли» факты того, что иной раз в компаниях холдинга проводили оплаты поставщикам, не взирая на запрет со стороны УК и несоответствия расхода, утвержденному бюджету. Естественно что, получив такой мощный инструмент контроля, как единую ERP систему, это незамедлительно дало положительный результат.

5 Осуществленные доработки в ходе внедрения подсистемы

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

1. Устранены ошибки типовой конфигурации УПП 1.3..
2. Суммы, по заявкам на расходование ДС и планам поступления ДС, стали поступать в платёжный календарь только после утверждения.
3. Изменилась схема выбора маршрута согласования заявки на расходование ДС. Маршрут согласования заявки стал зависеть от:
   1. статьи ДС;
   2. суммы заявки.
   3. Только утвержденные платежные поручения можно выгрузить в клиент-банк. В типовой УПП выгружаются также и неутвержденные п/п.
   4. Устранены возможности обхода запрета проведения платежа без заявки.
   5. Осуществлено хранение истории согласования заявок. В любой момент пользователь может посмотреть, у кого находится заявка на согласовании и кто (когда) согласовал заявку.
   6. Разработан механизм «переписки» по заявкам, используемый при прохождении заявки по маршруту согласования.
   7. Доработана обработка согласования заявок. Запрос, используемый в динамическом списке, был неоптимальным, в результате чего, при большом объеме заявок, в момент согласования обработка зависала на 2-3 минуты. Переписка с разработчиками по поводу данной ошибки результатов не давала, поэтому ошибка была исправлена самостоятельно.
   8. Разработана обработка по включению заявки в платежный календарь, т.е. после того, как заявка была утверждена, дополнительно определялся порядок проведения платежей, другими словами, определялся порядок включения заявки в платежный календарь
   9. Разработан пакет отчетов (Платежный календарь, Cash Flow, состояние согласования заявок и т.д.), используемый в холдинге.

В приложении к данной статье есть СКД отчет для обработки согласования заявок.

6 Вывод

Если вы хотите избавиться от «кассовых разрывов», то планирование денежных потоков должно быть непрерывным процессом. Чем больше предприятие, чем сложнее его структура, чем больше видов деятельности, тем сложнее управлять потоками денежных средств. Поэтому единая ERP система - это мощный инструмент в планировании и контроле движения денежных средств.

Платежный календарь в 1С:ERP Управление предприятием 2 отображает информацию о:

• доступном остатке денежных средств на наличных и безналичных счетах компании;
• планируемых поступлениях и расходованиях денежных средств.

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

В верхней части обработки «Платежный календарь» доступен выбор следующих опций:

• период формирования;
• организации;
• валюта;
• отбор по конкретным счетам организации.

Форма платежного календаря в 1С:ERP Управление предприятием 2 приведена на рис. 1.

Рисунок 1 - Платежный календарь в 1С:ERP Управление предприятием 2

Документами-основаниями для заполнения Платежного календаря являются:

• «Заказ клиента»;
• «Заказ поставщику»;
• «Распоряжение на перемещение денежных средств»;
• «Заявка на расходование ДС».

Настройки Платежного календаря в «1С:ERP Управление предприятием 2»

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

Рисунок 2 – Настройки Платежного календаря

В Платежном календаре отображаются заявки, которые имеют статус «Согласована» или «Не согласована», если такой вариант указан в настройках (рис. 2). Заявки со статусами «К оплате» и «Отклонена» в Платежном календаре не видны.

Виды Платежного календаря

Платежный календарь может быть сформирован в 3 видах (рис. 3).

Рисунок 3 - Выбор вида Платежного календаря

Заявки - Календарь (рис.4)

В левой части формы выводится информация о заявках на расходование денежных средств.

В правой части формы отражается информация о:

Рисунок 4 - Платежный календарь вида «Заявки – Календарь»

Календарь – Платежи (рис. 5)

В верхней части формы Платежного календаря выводятся данные о:

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

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

Рисунок 5 - Платежный календарь вида «Календарь – Платежи»

Список заявок (рис. 6)

В списке заявок выводятся заявки, которые имеют статус «Согласована» или «Не согласована», если такая возможность указана в настройках (рис. 2).

Рисунок 6 - Платежный календарь вида «Список заявок»

Раздел «Календарь»

В графе «Просрочено» видна задолженность нашей организации по:

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

Внимание!!! При вводе начальных остатков по кассе и расчетным счетам они также будут отражены в Платежном календаре в графе «Просрочено».

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

Денежные средства в пути выводятся в платежном календаре в виде 2 сумм:

• со знаком «-» для счета, с которого денежные средства будут отправлены;
• со знаком «+» для счета, на который денежные средства должны поступить (рис. 7).

Операция отражается на основании документа «Распоряжение на перемещение денежных средств» с видом операции «Инкассация ДС в банк» по состоянию на планируемую дату отправки денежных средств (дата платежа) (рис. 9). Распоряжение должно иметь статус «Согласовано» либо «К оплате».

Рисунок 7 - Отображение в ПК операции инкассации ДС после проведения документа «Распоряжение на перемещение денежных средств» с видом операции «Инкассация ДС в банк»

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

Рисунок 8 - Отображение в ПК операции инкассации ДС после проведения документа «Расходный кассовый ордер» с видом операции «Инкассация в банк»

Дата планируемого поступления определяется суммированием даты планируемой отправки ДС (рис. 9) и срока инкассации (рис. 10).

Рисунок 9 – Указание даты планируемого платежа в документе «Распоряжение на перемещение денежных средств»

Рисунок 10 - Установка срока инкассации в справочнике «Касса организации»

При составлении Платежного календаря автоматически проверяется его выполнимость – т.е. достаточность запасов денежных средств для оплаты в местах их хранения.

Планируемые суммы поступлений и платежей выводятся в виде ежедневной сводной. Для получения более детальной информации служит раздел «Платежи».

Раздел «Платежи»

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

В информации о платежах указана планируемая дата платежа, но не указана пометка «просроченный».

Блок платежей позволяет:

Раздел «Заявки»

В «1С: ERP Управление предприятием 2» редакция 2.2.3.190 предусмотрена возможность включения или отключения оформления «Заявок на расходование ДС».

Эта настройка доступна в разделе «НСИ и администрирование», группе «Настройка НСИ и разделов» пункт «Казначейство» (рис. 11).

Рисунок 11 - Настройки использования в программе 1С: ERP Управление предприятием 2 «Заявок на расходование денежных средств»

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

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

Рисунок 12 - Настройка использования «Заявок на расходование денежных средств» и «Распоряжений на перемещение ДС» в справочнике «Касса организации»

Аналогичные галочки можно установить и в справочнике «Банковский счет организации» (рис. 13).

Рисунок 13 - Настройка использования «Заявок на расходование ДС» в справочнике «Банковского счета организации»

Внимание!!! Данные настройки не влияют на порядок формирования Платежного календаря.

В «1С: ERP Управление предприятием 2» документ «Заявка на расходование ДС» предназначен для отображения планируемый расходов денежных средств следующих видов:

• выдача денежных средств подотчетному лицу;
• перечисление денежных средств поставщику;
• возврат денежных средств клиенту;
• оплата по кредиту;
• таможенный платеж;
• оплата в другую организацию;
• прочие расходы денежных средств и др.

Использование заявок на расходование ДС позволяет выполнить следующие задачи:

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

Заявки отображаются в Платежном календаре в зависимости от статуса и заполнения поля «Объект расчетов» (табл.1, табл. 2)

Таблица 1. Варианты влияния заявок на формирование Платежного календаря, если в настройках не указано «Отображать в календаре несогласованные заявки на расходование денежных средств»

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

Таблица 2. Варианты влияния заявок на формирование Платежного календаря, если в настройках указано «Отображать в календаре несогласованные заявки на расходование денежных средств»

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

Организация ООО «Конфетпром» планирует оплатить 22.05.17 поставщику ООО «Невский берег» 74 998,44 за товары (рис. 20). В программе были введены документы «Заказ поставщику» и «Заявка на расходование ДС». На рис. 15-20 приведено изменение Платежного календаря в зависимости от заполнения полей «Заявки на расходование ДС».

Рисунок 20 - Отображение в Платежном календаре документа «Заказ поставщику», без проведения документа «Заявка на расходование ДС».

Отправить эту статью на мою почту

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

В 1С представлено два варианта работы со счетами на оплату в 1С:

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

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

Какой из вышеперечисленных вариантов будет применяться зависит от значения константы Использовать счета на оплату клиентам и устанавливается оно в разделе НСИ и Администрирование → Продажи → Оптовые продажи → Счет на оплату.

Документ Счет на оплату 1С 8.3

Создание счета в 1с 8.3 возможно путем ввода нового из Реестра торговых документов, а так же вводом на основании, при соблюдении некоторых условий

По Заказу клиента, если:

В нем выбран договор с порядком взаимодействия По заказам;

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

Счет на оплату в 1С создается на основании Реализации товаров и услуг если:

Используется договор, в котором определен порядок По накладным;

Договор не нужен, но в соглашении прописаны правила расчетов По накладным.

Счет в 1С 8.3 может быть создан на основании любого из вышеуказанных документов, при условии, что правила взаиморасчетов с клиентом По договорам.

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

Здесь представлено две рабочие закладки: Этапы и оплаты и Счета на оплату. Каждая предполагает свои реквизиты и выполняет определенные функции.

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

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

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

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

Заполнение данных выглядит так:

Детализация: По заказам;

Форма оплаты: Наличная;

Варианты оплаты: предоплата (до отгрузки) 50% и кредит (после отгрузки) 5дней 50%

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

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

Новый счет в 1С содержит следующую информацию:

В шапке: на основании чего выставлен, когда, кому и от кого;

В Этапах оплаты отображаются форма оплаты, банковский счет и/или касса и график оплаты;

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

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

Все созданные счета на оплату 1С 8.3 доступны в списке счетов в разделе «Продажи». Просмотреть все выставленные счета по объекту расчетов можно с помощью отчета «Связанные документы», и открыть их непосредственно из отчета кликнув на соответствующие строки отчета.

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

Печатная форма Счет на оплату 1С 8.3

Формирование только печатной формы Счет на 1С 8.3 без хранения ее в базе, доступно из нижеприведенных объектов системы:

Из заказа клиента, при соблюдении следующих условий:

В нем используется договор с детализацией расчетов По заказам;

Договор не нужен, но в соглашении вариант расчетов По заказам.

Из реализации товаров и услуг в том случае если:

Используется договор, в котором взаиморасчеты осуществляются По накладным;

Договор не нужен, но в соглашении указывается детализация По накладным.

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

Так же для счетов в 1С реализована возможность вывода счета с факсимиле. Для этого в карточке организации в настройках печати должна быть добавлена факсимильная печать (методика добавления доступна по ссылке «Как создать факсимиле?»). Распечатка такого счета на оплату в 1С осуществляется по команде Печать выбором соответствующего пункта меню.

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

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

Рисунок 1. Форма документа «Заявка на расходование ДС», вид операции «Оплата поставщику» (не заполненная)
Реквизиты документа «Заявка на расходование ДС» необходимо заполнить следующим образом:
Вкладка Основное
Номер – формируется автоматически при проведении, вручную не устанавливается.
Дата – при создании устанавливается текущая дата.
Организация – необходимо выбрать из предложенного списка организаций, с помощью кнопки, либо путем ввода наименования в поле будет предложено для выбора требуемое значение.
Подразделение – из справочника «Структура предприятия» необходимо выбрать подразделение, по которому должен произойти платеж.
Заявитель – по умолчанию указывается текущий пользователь системы, создающий заявку.
Планирование – по умолчанию устанавливается «В валюте платежа» не подлежит изменению.
Сумма – указывается сумма требуемого платежа.
Валюта – указывается валюта требуемого платежа.
Операция – отражается выбранный при создании вид операции документа «Заявка на расходование ДС»
Дата платежа – указывается дата, на которую необходимо запланировать платеж поставщику.
Форма оплаты – по умолчанию устанавливается «В любой форме» не подлежит изменению.
Получатель – указывается поставщик из справочника «Контрагенты», которому необходимо произвести оплату.
Счет получателя – при выборе «Получателя» автоматически устанавливается счет получателя, при необходимости, если на предоставленном поставщиком «Счете на оплату» указан иной счет, необходимо из справочника «Банковские счета» выбрать требуемый.
Сверх лимита – если в системе осуществляется ведение системы лимитирования расхода денежных средств в разрезе филиалов и статей движения денежных средств, соответственно если сумма осуществляемого платежа не была ранее включена в лимит, при проведении документа пользователь получит сообщение об ошибке и заявка не проведется.

Рисунок 2. Пример ошибки при проведении заявки, по которой не был запланирован лимит.
Для проведения заявки сверх лимита, необходимо установить флаг «Сверх лимита»
Перечисление в бюджет – данный флаг устанавливается, если платеж является перечислением в бюджет. Установка флага позволяет ввести требуемые для платежей в бюджет значения КБК, ОКТМО и т.п.

Рисунок 3. Пример установки флага «Перечисление в бюджет».
УИП – уникальный идентификатор платежа, указывается только в том случае если это предусмотрено договором с получателем платежа.
Назначение платежа - в программе предусмотрено несколько вариантов автозаполнения назначения платежа по кнопке "Вставить».

Рисунок 4. Варианты автозаполнения поля «Назначение платежа».
Список документов, в т.ч. НДС - отразит информацию об объектах расчетов с вкладки "расшифровка платежа"

В т.ч НДС (18%) (на всю сумму), В т.ч. НДС (10%) (на всю сумму), Без налога (НДС) - к введенному тексту добавят информацию о НДС.

Текст из банковского счета получателя - вставит текст, указанный в поле "Текст назначения платежа" из карточки р/с контрагента.

Рисунок 5. Пример заполнения вкладки «Основное».

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

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

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

Рисунок 8. Пример автоматически созданного документа «Списание безналичных ДС» по заявке с видом операции «Оплата поставщику».

Возврат оплаты клиенту
Для оформления операций возврата оплаты клиентам предназначен вид операции документа «Заявка на расходование ДС» - «Возврат оплаты клиенту».
Состав реквизитов документа «Заявка на расходование ДС» с данным видом операции идентичен составу реквизитов при оплате поставщику, различие только в виде контрагента и объекте расчетов.

Рисунок 9. Форма документа «Заявка на расходование ДС», вид операции «Возврат оплаты клиенту»
Получатель – указывается клиент из справочника «Контрагенты», которому необходимо произвести оплату.
Объект расчетов – в качестве объекта расчетов можно указать «Договор с контрагентом» (при данном виде операции документа заявка при выборе доступны договоры с типом взаимоотношений «С покупателем/заказчиком») или согласованный документ «Заказ клиента».
Покупатель – поле заполняется автоматически при выборе объекта расчетов. Устанавливается элемент справочника «Партнеры», указанный в соответствующем поле объекта расчетов.

Рисунок 10. Пример заполнения вкладки «Расшифровка платежа».
После прохождения всех этапов согласования, документу «Заявка на расходование ДС» будет присвоен статус «К оплате» и автоматически создан документ «Списание безналичных ДС».

Рисунок 11. Пример автоматически созданного документа «Списание безналичных ДС» по заявке с видом операции «Возврат оплаты клиенту».

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

Рисунок 12. Форма документа «Заявка на расходование ДС», вид операции «Выдача подотчетнику»
Подотчетное лицо – указывается сотрудник из справочника «Физические лица», которому необходимо произвести перечисление денег подотчет.
Отчитаться – из предложенного перечня периодов необходимо указать период, до которого подотчетнику требуется отчитаться по полученной сумме.

Рисунок 13. Пример заполнения вкладки «Расшифровка платежа».
После прохождения всех этапов согласования, документу «Заявка на расходование ДС» будет присвоен статус «К оплате» и автоматически создан документ «Списание безналичных ДС».

Рисунок 14. Пример автоматически созданного документа «Списание безналичных ДС» по заявке с видом операции «Выдача подотчетнику».

1. Введение

Планирование денежных средств - одна из главных задач управленческого учета в отличии от учета бухгалтерского.

Конечно, между УУ и БУ есть и другие существенные различие (разные требования к аналитике, к оценке и переоценке активов/обязательств, необходимость создания резервов и т.д.), но необходимость решать задачи планирования – это самая сложная из них.
Сложность планирования заключается не только в подготовке плана (его расчету, формированию по разным сценариям), но необходимо еще:

• Выполнять перепланирование;
• Актуализировать планы, переносить корректировки на следующие периоды;
• Проводить план - фактный анализ.

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

Учет нужно наладить, да, но не в ущерб планированию.
Конечно же, планированием все равно занимаются (но не в «1С», а XLS). И самую первую, основную задачу (которую и стараются решить) – это планирование денежных средств.

• (1) Стратегическое (бюджетирование);
• (2) Оперативное.

И если бюджетирование (конечно, при подходе к планированию «сверху-вниз»), можно осуществлять с помощью XLS, то выполнять оперативное планирование – нельзя.
Суть в том, что с таблицами бюджетов чаще всего работают минимум пользователей (1-2 человека). Для большинства предприятий количество статей бюджетирования и пр. аналитик – их не так много. Т.е все можно обработать «ручками» в XLS.

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

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

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

И эти заявки, соответственно, нужно вовремя обрабатывать, принимать / отклонять, «ставить в план» и оплачивать.

Итого: оперативное планирование д/с - это самая первая из задач планирования , которая должна быть автоматизирована в «1С» у любого предприятия.

И в результате планирования, финансовый департамент / казначейство должны «видеть» в системе:

• Когда, кому, c какого расчетного счета/кассы, на какую сумму нужно оплатить;
• Какой остаток д/c будет на «такую-то» дату c учетом текущих остатков, запланированных расходов и поступлений д/c. Нужно избегать т.н. «кассовых разрывов».

  Т.е возникает необходимость работать с платежным календарем.

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

  Т.е возникает необходимость работать с календарем расчетов.

Цель данной статьи – рассказать о возможностях автоматизации оперативного планирования д/c. При этом, будет проведен сравнительный анализ 3-х разных тиражных конфигураций (две – типовые от «1С», одна - специализированная от компании wiseadvice ).

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

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

На данный момент фирма «1С» еще не выпустила долгожданную, новую редакцию УПП (ред 2). И по этому, будем ориентироваться на то, что доступно - соответствующие подсистемы УПП 1.3:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Возможность указывать ЦФУ и т.д. – отсутствует.

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

1. Отсутствует возможность запланировать перемещение д/c между расчетными счетами, cо счета в кассу и прочее.
1. Процесс согласования:
   1. Существует возможность согласовывать ЗРДС, но отсутствует возможность согласовывать планируемое поступление д/с.
   2. На практике возникает необходимость выполнять согласование за других сотрудников. При этом, в системе нужно фиксировать еще и информацию о том «кто и за кого выполнил согласование».

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

      Резюмируя - возможность согласовывать за другого исполнителя, возможность указать кто и за кого имеет право согласовывать – отсутствует.

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

1. Отчеты, права доступа.
   1. Востребована возможность ограничения доступа к заявкам только по доступным авторам / исполнителям (согласователям); по доступным пользователю подразделениям.
   2. Отсутствует отчетность по контролю (по дням и интервалам) фактической и запланированной задолженности. Это актуально и для покупателей и для поставщиков.
   3. Отчетность и часть функционала не пригодны для работы в режиме тонкого/web-клиента.
2. Учет по регулярным соглашениям, договорам.
   1. Часто встречаются ситуации, когда необходимо регулярно осуществлять оплату поставщикам. Например, арендные платежи и т.д.

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

   2. В договорах с покупателями, c поставщиками могут быть прописаны условия по проценту предоплаты, по срокам оплаты и т.д.

      В УПП не автоматизирован учет всей этой информации и (как следствие) автоматическое отражение ее в платежном календаре.

3. Возможности УТ 11.1

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

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

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

Функциональность отчета сильно расширилась (по сравнению с УПП 1.3) за счет использования системы компоновки данных. Теперь, отчет можно формировать в тонком/web-клиенте, сохранять в базе и назначать разным пользователям нужные им настройки.

Кроме планирования расхода и поступления д/с в УТ11 появилась функциональность планирования перемещения д/c. Для этих целей можно оформлять документы «Распоряжение на перемещение д/c».

По сравнению с УПП 1.3 для документа «Заявка на расходование д/c» увеличилось количество учитываемых видов хозяйственных операций:

Появилась возможность утверждать как документы «Заявка на расходование д/c», так и другие распоряжения:

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

К сожалению, в УТ11 (как и ранее) не предусмотрена возможность анализа календаря задолженности по поставщикам. Однако, доработать УТ11 по данной задаче .

Резюмируя: новые методологические решения «1С» вместе с возможностями платформы 8.2 предоставляют хорошую базу для автоматизации задач оперативного планирования и контроля д/c.

Но вместе с тем надо понимать, что конфигурация УТ11 не является полноценным, готовым решением для автоматизации казначейства и планирования д/c.

• Во-первых, в УТ11 в очень упрощенном виде реализован механизм согласования/утверждения заявок на расход и др. документов планирования д/c. Т.е нет механизмов маршрутизации, процесс утверждения заявок сведен к простой установки статусов.
• Во-вторых, в УТ11 нет подсистемы бюджетирования и (как следствие) нет функционала контроля заявки по запланированным бюджетам.

4. Возможности WA: Финансист

Исторически конфигурация «WA:Финансист» была разработана на базе продукта «Управление казначейством».

И при этом, в новое решение «Финансист» от компании WiseAdvice входят еще:

• Подсистема бюджетного планирования;
• Подсистема управления договорами;
• Подсистема формирования и учета фактических платежей;
• Гибкий, настраиваемый механизм формирования/заполнения документов на основе шаблонов;
• Гибкая, настраиваемая подсистема интеграции с клиент-банком.

Рассмотрим основные функциональные возможности «WA:Финансист» в части казначейства - от учета условий по договорам до формирования платежного календаря.

1. В процессе утверждения заявки можно не только согласовать/отклонить документ (как это сделано в УПП), но доступны и другие функции: например, отправить документ на доработку, либо запросить доп. информацию.

   Весь этот процесс автоматизирован, соответственно предусмотрена отчетность о состоянии отработки согласования документа.

5. Итоги

Выводы:

1. Для автоматизации работы финансовых департаментов, казначейств, организаций со сложной орг. структурой наиболее подходящим решением является «WA:Финансист » .

   Данное решение развивалось и эволюционировало длительное время, соответственно аккумулировало специфику и требования разных фин. департаментов и казначейств. Общие трудозатраты на разработку решения составили более 5000 чел/часов.

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

   Так как в решении заложены механизмы двухстороннего обмена со всеми основными типовыми конфигурациями, то интеграция в имеющуюся структуру (обмен данными с базами УТ, УПП, Комплексная, Бух) будет не сложной.

2. Для автоматизации фин.департамента / казначейства в рамках проекта комплексной автоматизации лучше всего подойдем решение на базе УПП .

   При этом нужно понимать, функциональность УПП потребует доработок.

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

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

3. Для крупных организаций, для автоматизации департамента казначейства УТ11 не подходит.

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

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

   Однако, УТ11 отлично подойдет для автоматизации (в т.ч. оперативного планирования д/c) небольших фин. отделов компаний .