Файл: Разработка конфигурации «Разработка бюджетов» в среде 1С: Предприятие 8.3..pdf

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

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

Система требований к информации для процесса бюджетирования:

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

2. Своевременность. Данное требование исключительно важно, поскольку для пользователя имеют значение не данные вообще, а данные в нужном объеме и в нужное время.

3. Достаточность, то есть оптимальность количества информации, необходимой для процесса бюджетирования.

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

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

6. Полезность. Информация должна удовлетворять интересы пользователей.

7. Понятность. Информация не должна требовать значительных усилий для ее расшифровки.

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

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

10. Гибкость и инициативность. Должна обеспечиваться вся полнота информационных интересов в условиях меняющихся управленческих ситуаций.

11. Оперативность. Предоставление в сроки, позволяющие вовремя принять эффективное хозяйственное решение.

ГЛАВА 2. РАЗРАБОТКА ТЕХНИЧЕСКОГО ПРОЕКТА БЮДЖЕТИРОВАНИЯ

2.1 ОБЗОР АНАЛОГИЧНЫХ СИСТЕМ

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

Этим объясняется большой интерес со стороны предприятий к системам бюджетирования, представленным на рынке.

Существуют зарубежные системы, которые представленные на российском рынке: Active Planner (ERA Budgeting), Adaytum e.Planning, Comshare MPC, Hyperion Pillar, Oracle Financial Analyser, Prophix, а так же российские системы бюджетирования: BPlan, BussinesBuilder PlanDesigner, Инталев, Контур Корпорация Бюджет.

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

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

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

2.2 ЭСКИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

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

2.3 ЛОГИЧЕСКАЯ МОДЕЛЬ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

2.4 ФИЗИЧЕСКАЯ МОДЕЛЬ БЮДЖЕТИРОВАНИЯ

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

ГЛАВА 3. РЕАЛИЗАЦИЯ ПРОЕКТА РАЗРАБОТКИ БЮДЖЕТА

3.1 РАЗРАБОТКА ЭКРАННЫХ ФОРМ

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

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

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

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

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

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

3.2 РАЗРАБОТКА МОДУЛЕЙ ДЛЯ ПРИКЛАДНЫХ РЕШЕНИЙ

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

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

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

3.3 РАЗРАБОТКА ОТЧЕТОВ

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

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

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

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

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

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

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

3.4 РОЛИ ПОЛЬЗОВАТЕЛЕЙ

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