ВНЕДРЕНИЕ 1С:ERP и 1С:Управление холдингом     Главная     Проекты, результаты     Консультации (Новый раздел!!)     Обратная связь. Отзывы, рекомендации    
 












Казначейство 1С:ERP/1С:Управление холдингом

  • Архив

    «   Июль 2018   »
    Пн Вт Ср Чт Пт Сб Вс
                1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31          

Казначейство в 1С:Управление холдингом. Прочие сервисные функции, отчетность по БДДС (часть 6 из 6)

5 Прочие сервисы, отчетность по БДДС.

5.1 Разделение заявки


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




Например, поровну, на указанное количество частей




5.2 Перенос, перераспределение лимитов, резервов


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

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

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

Для примера, оформим перенес половину суммы резерва (по оплате лицензирования) из текущего месяца в следующий месяц.




5.2. Отчетность по лимитам, резервам, графикам, движению д/с.

  1. Для контроля над лимитами, резервами и их исполнения предусмотрен отчет «Остатки лимитов»







2. Для контроля над графиками предусмотрен отчет «Исполнение графиков оплаты»





3. Для анализа БДДС предусмотрен отчет «Анализ бюджета движения денежных средств»




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

Спасибо за Ваше внимание. :-)

С уважением, Горский М.А.

Казначейство в 1С:Управление холдингом. Планирование по договорам, финансовые инструменты (часть 5 из 6)

4 Планирование по договорам, фин. инструментам.

4.1 Формирование заявок на оплату по данным графиков оплат


В программе предусмотрена возможность автоматически планировать движения д/c в соответствии с графиком платежей. Графики платежей можно заполнить из договора с контрагентом, следующим образом (перейди в карточку договора):




Перейти к заполнению графика (график исполнения коммерческого договора).





Формирование заявок (в соответствии с графиком) производится с помощью специальной обработки «Исполнение коммерческих договоров».




4.2 Планирование движения д/c по данным финансовых инструментов.


В программе предусмотрен отдельный учет договоров в части финансовых инструментов.

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

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

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




Укажем период действия, сумму договора, процентную ставку.







График будет рассчитан автоматически.





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






Формирование заявок (в соответствии с графиком) производится с помощью специальной обработки «Исполнение финансовых договоров».

Казначейство в 1С:Управление холдингом. Оперативное планирование и фактическое движение денежных средств (часть 4 из 6)

3 Оперативное планирование и факт. движение ДС.

3.1 Резервирование бюджетов


Как было сказано ранее, лимиты ДДС по бюджетам (Бизнес-планы ДДС) зачастую могут уточняться (например, сумма по статье может быть детализирована по контрагентам, по доп. аналитикам, например, мероприятиям и т.д).

Установка лимитов ДС в оперативном контуре будет выполняться документом «Резервирование бюджетов». Такие документы удобно ввести на основании Бизнес-планов ДДС. При этом, установка и контроль лимитов будет проводиться в разрезе предопределенного сценария – «резерв».





И далее, при оперативном планирование расхода ДС (в момент проведения заявки на оплату), программа будет проверять текущие оперативные остатки по лимитам. И если есть превышение лимита, то программа не позволит провести такую заявку, будет выдано соответствующее предупреждение.



Для включения запрета проведения документов при превышении лимита, перейдем в раздел «Общие справочники и настройки/Настройка параметров/Казначейство».




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


Итак, введем документы Резервирование бюджетов на период – Сентябрь 2017 г.

Обратим внимание на следующие моменты:


  • Для документа «Резервирование бюджета» маршрут согласования создавать не будем. Установим признак «Вне маршрута» и статус «Утвержден»







  • Организацию укажем «МСК УК (Управленческие функции)», при этом ЦФО – оставим то значение, которое было указано в бизнес-плане.






3.2 Маршруты согласование заявки на оплату поставщику


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

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

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


Перейдем в раздел «Процессы и согласования/Шаблоны процессов».

Создадим новый шаблон – «Процесс согласования заявок на оплату». В качестве назначения процесса укажем – «Маршрут согласования». Тип объекта согласования – «Заявка на операцию».





Создадим следующий маршрут согласования:






Настройка условий выбора маршрута выполняется в специальном конструкторе. Т.е. всегда можно настроить – при выполнении каких условий (или групп условий) выполнять какие действия, к каким этапам согласования программа должны перейти.




Для проверки того, как сработают условия маршрутизации в зависимости от параметров заявки, предусмотрена функционал «Отобразить» в проверке маршрута.




В качестве отдельного этапа (сетевой диаграммы процесса) может выступить этап «Оповещение».

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

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

Для настройки содержания оповещения необходимо настроить шаблон оповещения:




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




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

Т.е. согласант всегда будет получать оповещения, видеть какие этапы он в данный момент должен согласовать, и выполнить согласование он сможет прямо из журнала «Мои задачи и оповещения».

Что бы включить формирование оповещений по событиям, следует перейти в раздел «Процессы и согласования/Настройки оповещений» и добавить такую запись:



И ,наконец, после того как шаблон процесса согласования полностью настроен, необходимо указать этот шаблон в регламенте подготовки отчетности. В нашем примере, требуется в регламенте «Установка и контроль лимитов ДДС» настроить матрицу полномочий согласования экземпляров отчетов – указать в ней шаблон процесса согласования.




Для документа Заявка на операцию указать шаблон процесса «Процесс согласования заявок на оплату».




3.3 Согласование заявок по маршруте



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



Заполним документ Заявка на операцию с видом «БДДС (Расход) расчеты с контрагентами».

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

При попытке проведения документа получим сообщение о превышении лимита.




Исправим эту ситуацию, сформировав заявку корректно. Укажем источник лимитов (документ резервирования бюджета), укажем доступную сумму.

Заполним контрагента, договор; перейдем на закладку «Контроль лимитов».


Увидим – какой на данный момент остаток лимита (с учетом текущей операции) и какой лимит был запланирован.





Проведем документ и увидим, что документ получим статус «На утверждении»

По кнопке «Ход согласования» откроем маршрут и увидим этап, на котором в данным момент находится заявка.





Текущий этап – выделен голубым цветом.





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

Перейдем в раздел «Процессы и согласования/Мои задачи и оповещения».

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

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





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

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





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




Это означает, что хотя заявка и проходит по контролю лимитов, но не проходит по директиве контроля платежа.

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


По кнопке «Согласовать документ» перейдем к выполнению согласования текущего этапа.




Проставим визу (пояснение) и нажмем «Согласовать».




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

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


  • Отклонить заявку на предыдущий шаг согласования;

  • Передать заявку на согласования дополнительным согласующим (т.е по необходимости можно добавит согласантов в текущий маршрут и перенаправить заявку им).





3.4 Работа с платежным календарем.


Итак, в данный момент 2 заявки на оплату находятся на этапе «соглования» у казначея.

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

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

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

Т.е казначей может смоделировать, например, ситуацию №1 «допланирования» ожидаемого поступления д/c от клиента и проанализировать и сохранить этот «сценарий» развития событий (такой вариант платежного календаря). Затем, смоделировать ситуацию №2, когда ожидаемого поступления д/с не случилось, а необходимо закрыть нехватку д/c через перемещение д/c с другого расчетного счета и частично сдвинуть даты оплаты. Итого, можно будет сравнить оба варианта развития событий и выбрать более выигрышный.

Функционал платежного календаря в УХ предоставляет богатые возможности для казначея, рассмотрим все это на примерах.



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

Настроить рад параметров работы платежного календаря:


  • Горизонты формирования календаря (кол-во дней);

  • Учитывать или нет (1 или 0, или например - 0.5 – тогда «на половину учитываем») документы заявок (в том числе не утвержденные, находящиеся в процессе согласования) при формировании платежного календаря.



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

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








Зарегистрировать текущие начальные остатки д/с:

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

Регистрация начальных остатков д/c осуществляется через оформление документа «Корректировка начальных остатков». При этом, это документ разумеется можно заполнить автоматически, по данным бух. учета (m.е по текущему дт 51 счета).



Итак, зарегистрируем начальные остатки по 2 юр. лицам и их банковских счетам.





Фактические поступления/выбытия д/с будут отражены в программе через документы «Отражение фактических данных бюджетирования». Такие документы будут сформированы в программе автоматически, в момент отражения факт. бухгалтерских документов движения д/c (поступления/списания д/c по счету). Такое поведение системы определяется вот этими настройками:






Перейдем в раздел «Планирование и контроль/Платежный календарь».

Выполним установку следующих, ключевых параметров:

  • Группировки установим: по организации и банковскому счету;
  • Период установим: c текущей даты до даты конца текущего месяца;
Отбор по организации: установим по консолидирующей группе МСК Энергетика +





Сформируем платежный календарь (календарь будет сформирован с текущей даты и до даты окончания месяца).

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

Красный цвет означаем то, что у нас образовался кассовый разрыв по счету «Банковский счет не определен». Это возникло потому, что счет оплаты в заявках не определен.

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

  • Изменим счет выбранных заявок. Установим счет – ВТБ 24.





  • В результате получим, что «Банковский счет не определен» - исключен из календаря, однако на 05/09 присутствует кассовый разрыв на сумму 4000. Суть в том, что планируемые расход (34 тыс. руб. суммарно по 2 заявкам) превышает остаток д/c на счете.





  • C помощью функционала «отложить/отложенные» можно отложить на время заявку (перенести ее в стоп-лист). Затем, вернуть ее из отложенных.







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





  • Можно сдвигать дату оплаты заявок на указанную, на крайнюю дату

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




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





3.5 Формирование реестра платежей.


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




В нашем примере главный бухгалтер формируем и проводит реестр в статусе «Утвержден».

Платежные поручения формируются по кнопке «Сформировать платежные поручения».





3.6 Отражение факта, разнесение выписок по аналитикам бюджетирования.


Выгрузка платежек и загрузка выписок из клиент-банк осуществляется стандартно, средствами обработки «Обмен с банком»




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

Обратим внимание на то, по факту списания с расчетного счета в программе автоматически будут сформированы документы «Отражение фактических данных».




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




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

Такой алгоритм можно настроить в обработке «Разнесение банковской выписки по аналитикам планирования». Заполнение будет осуществлятся на основе шаблонов ананалитик. В программе можно быть создано множество шаблонов заполнения.






Приведем пример шаблона, который устанавливает значение аналитики «Проект». Шаблон (правило) срабатывает по любым организациям и контрагентам. При этом проверяется содержание назначения платежа. Т.е если поле «назначение платежа» содержит сочетание слов «Основной договор», то в этом случае устанавливается аналитика «Проект основной» в поле проект.

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

Казначейство в 1С:Управление холдингом. Формирование лимитирующих бюджетов (часть 3 из 6)

2 Формирование бюджетов.

2.1 Формирование структуры бизнес-плана ДДС.


Перейдем в раздел «Настройка модели отчетности» и введем новый вид отчета «Бизнес-план ДДС»



Обратим внимание на следующие поля.

  • Назначение – нужно указать Бюджет движения денежных средств. Это необходимо, так как создаваемый нами «Бизнес-план ДДС» будет нацелен именно на установку лимитов по БДДС. Т. е. при его проведении будут формироваться записи в регистр накопления «Бюджет движения денежных средств»;

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

  • Объект для согласования значений – укажем Экземпляр отчета. Будем считать, что утверждение бизнес-плана по каждому ЦФО будет производится отдельно, ответственным за ЦФО сотрудником. Таким образом, сначала бизнес-план будет введем по всем ЦФО сразу (на уровне сводной таблицы), а утверждение в рамках отдельных ЦФО будет производится на уровне экземпляра отчета Бизнес-план (для каждого ЦФО отдельно).





Определим следующую структуру бюджета:


  • Строки бюджета – включим в состав 3 статьи БДДС. Две из которых будут иметь дополнительное аналитическое раскрытие по мероприятиям (введем такую доп. аналитику как субконто корпоративное);

  • Показатель – сумма лимита в руб.





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



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





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




Для каждого показателя нужно установить признак «Для установки лимитов». Тогда по нему будет производиться движение в регистр «Бюджет движения денежных средств»;




2.2 Формирование бланка сводной таблицы бизнес-плана ДДС.


Создадим новый банк – бланк сводной таблицы.




Настроим состав строк. Укажем, какие строки будут отображаться в сводной таблице.





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





Настроим периодичность (колонки) сводной таблицы






Настроим аналитики раскрытия строк. Для этого перетащим в строки:

  • Организацию – аналитику из шапки;
  • Мероприятия – аналитику из доступных полей;





2.3 Ввод данных в сводную таблицу.


По «F5» перейдем к вводу данных в сводную таблицу.

Укажем период вводимых данных и сценарий.

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

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




Сохраним данные.


2.4 Утверждение лимитов ДДС по ЦФО.


Перейдем в раздел «Планирование и контроль/Экземпляры отчетов» и введем Бизнес-план ДДС по каждому ЦФО.




Укажем способ вывода – «Дерево строк…»




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


Переведем документ «отчет Бизнес-план ДДС» в статус утвержден.





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


Казначейство в 1С:Управление холдингом. Ввод основных НСИ (часть 2 из 6)

1. Основные НСИ



1.1 Общие настройки УХ.



В разделе «Общие настройки и справочники/Настройки параметров/Общие» - установим валюту упр учета – руб. Установим периодичность оперативного планирования – Месяц. Так же проверим значения остальных общих настроек.







1.2 Финансовая структура.



Перейдем в раздел «Общие справочники и настройки».

Введем в справочник «Организационные единицы» 2 юр. лица:


  • МСК УК (управленческие функции)

  • МСК Трейдинг (Закупка п продажа электроэнергии



Объединим эти юр лица в рамках консолидирующей орг. единицы «МСК Энергетика +». Так же для этой (и всех последующих) организационных единиц - укажем валюту и обязательно включим признак контроля расходов по бюджетам.







Далее, введем все необходимые ЦФО, как элементы справочника «орг. единицы», в иерархии юр лиц, c типом - «ЦФО»







1.2 Периоды.



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






1.2 Валюты.



Заполним справочник «Валюты». Установим курсы валют.






1.2 Сценарии.



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


  • План для лимитов – этот сценарий мы будем использовать для установки лимитов по бюджетам ДДС. Т.е. изначально лимиты по статьям бюджетирования и ЦФО будут устанавливаться по этому сценарию;

  • Резерв – этот сценарий мы будем использовать для установки (и дальнейшего оперативного) контроля лимитов по статьям ДДС, ЦФО и отдельным доп. аналитикам. Установка лимитов «по резервам» будет производится на основании ранее введенных «планов для лимитов». Таким образом, изначальные планы могут быть более подробно уточнены уже в контуре оперативного планирования.

  • Факт - этот сценарий будет автоматически задействован программой в тот момент, когда произойдет факт отражения операции по ДДС (например, факт списания с расчетного счета ранее запланированной к оплате суммы).








1.2 Регламент.



Перейдем в раздел «Настройка модели отчетности/Регламенты подготовки отчетности».

Введем новый регламент, назовем его «Установка и контроль лимитов ДДС».



Укажем, что будем формировать его по «МСК Энергетика +»




На закладке «Настройка регламента» укажем сценарий «План для лимитов». Матрицу полномочий согласования будем настраивать позже (когда займемся подзадачей – настройки маршрутов согласования заявок на оплату).




1.2 Управление отчетным периодом.


Перейдем в раздел «Планирование и контроль/Управление отчетным периодом».

Введем новую запись для периода «январь 2017-декабрь 2017» по регламенты «Установка и контроль лимитов ДДС».





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


Казначейство в 1С:Управление холдингом. Введение (часть 1 из 6)

Ожидается публикация...

.$.
 

    © 2011 Горский Михаил.