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

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

Содержание Введение Описание предметной области Глава 1. Теоретическая часть

1.1 Основные положения

1.2 Star UML

1.3 BPWin

1.4 1С предприятие Глава 2. Практическая часть

2.1 Star UML

2.2 BPWin

Глава 3. Разработка информационной системы в 1С

3.1 Создание справочников и документов

3.2 Создание регистров накопления и регистров сведений

3.3 Создание отчетов Заключение Список литературы

Введение

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

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

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

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

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

Во второй главе размещена практическая часть. Это диаграммы с использованием case-технологий и проектирование информационной системы в 1С.

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

Задачей курсовой является:

— проанализировать предметную область;

— спроектировать бизнес-процессы и построить контекстные диаграммы, используя BPWin и StarUML;

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

Описание предметной области

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

Телефонная компания предоставляет своим абонентам такие услуги как:

· Подключение телефона;

· Замена кабеля;

· Проводка интернет кабеля;

· Проводка телевизионного кабеля;

· Подключение полного пакета услуг;

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

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

Сотрудник телефонной компании работает с документами, такими как:

· справочник «Клиенты»;

· справочник «Сотрудники»;

· справочник «Номенклатура»;

· документ «Приходная накладная»;

· документ «Оказание услуг»;

· документ «Заключение договоров»;

· регистры «Остатки материалов» и «Цены»;

· отчеты о материалах.

Сформулируем требования к системе:

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

— справочник «Клиенты» содержит номер телефона и ФИО клиента, а также его личные данные: дату рождения, адрес и паспортные данные;

— справочник «Сотрудники» содержит код, ФИО сотрудника и должность, а также его личные данные: возраст, телефон, адрес;

— справочник «Номенклатура» является иерархическим и содержит данные о товарах и услугах;

— справочник «Склады» содержит информацию о складах телефонной компании, на которых находятся основные материалы, в данном проекте он один «Основной»;

— документ «Приходная накладная» предназначен для учета поступления товаров на склад, а также содержит сведения о товаре, его количестве, цене;

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

— документ «Заключение договоров» предназначен для хранения информации о сотруднике, клиенте и об услуге предоставленной клиенту после заключения договора;

— регистр накопления «Остатки материалов» используется для хранения остатков материалов, их количества, стоимости, наименования склада и дату поступления на склад;

— регистр сведений «Цены» предназначен хранения развернутых во времени розничных ценах материалов и стоимость услуг;

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

Глава 1. Теоретическая часть

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

· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

· требуемую пропускную способность системы;

· требуемое время реакции системы на запрос;

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

· простоту эксплуатации и поддержки системы;

· необходимую безопасность.

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

Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели — организации, требований к ИС, проекта ИС, требований к приложениям и т. д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитарии проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов — CASE-средств.

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

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

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

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

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

1.2 Star UML

StarUML — программный инструмент моделирования, который поддерживает UML (Унифицированный язык моделирования). StarUML ориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0. Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя концепцию профилей UML. Среда разработки StarUML™ превосходно настраивается в соответствии с требованиями пользователя и имеет высокую степень расширяемости, особенно в области своих функциональных возможностей. Использование StarUML, одного из ведущих программных инструментов моделирования, гарантирует достижение максимальной производительности и качества ваших программных проектов.

* Диаграмма классов (Сlass diagram). Диаграмма классов — визуальное отображение различных статических отношений между класс-подобными элементами. Диаграмма классов может содержать не только классы, но также и интерфейсы, перечислимые типы, пакеты, различные отношения, инстанции и их связи.

* Диаграмма прецедентов (Use case diagram). Диаграмма прецедентов — отображение отношений между вариантами использования (прецедентами) определенной системы или объекта и внешними акторами. Вариант использования отображает функции системы и то, как эти функции взаимодействуют с внешними акторами.

* Диаграмма последовательности (Sequence Diagram). Диаграмма последовательности отображает взаимодействие инстанций. Она является прямым отображением множества взаимных воздействий (InteractionInstanceSet) между элементами множества инстанций (CollaborationInstanceSet). В то время как Диаграмма сообщений роли ориентирована на классификаторы-роли, обычная Диаграмма сообщений — на инстанции.

* Диаграмма сообщений роли (Sequence Role Diagram). Диаграмма сообщений роли отображает взаимодействия в концепции ролей. Она является прямым отображением Interaction (множества взаимных сообщений между классификаторами-ролями) в пределах Collaboration. В то время как Диаграмма сообщений — отображение инстанций, Диаграмма сообщений роли — отображение классификаторов-ролей.

* Диаграмма коллаборации (Collaboration Diagram). Диаграмма коллаборации отображает взаимодействие между инстанциями. Она является прямым отображением модели взаимодействия инстанций, входящих в CollaborationInstanceSet. В то время как диаграмма коллаборации ролей — отображение классификаторов-ролей, обычная диаграмма коллаборации — отображение инстанций.

* Диаграмма коллаборации ролей. Диаграмма коллаборации ролей отображает взаимодействия между ролями. Она является прямым отображением модели взаимодействия классификаторов-ролей внутри коллаборации. В то время как обычная диаграмма коллаборации ориентирована на отображение инстанций, диаграмма коллаборации ролей — отображение классификаторов-ролей.

* Диаграмма состояний (Statechart Diagram). Диаграмма состояний выражает статическое поведение определенного объекта через состояния и переходы состояний. Хотя диаграмма состояний обычно используется, чтобы выразить поведение инстанций классов, она может также использоваться, чтобы выражать поведение и других элементов.

* Диаграмма действий (Activity Diagram). Диаграмма действий — специальная форма диаграммы состояний, которая является подходящей для того, чтобы отображать поток выполнения действий. Диаграмма действий в общем случае используется для отображения любых потоков обработки, но чаще всего применительно к объектам подобным классам, пакетам и операциям.

* Диаграмма компонентов (Component Diagram). Диаграмма компонентов отображает зависимость между программными компонентами. Элементы, которые составляют программные компоненты и элементы, которые реализуют эти компоненты, могут быть отображены на диаграмме компонентов.

* Диаграмма развертывания (Deployment Diagram). Диаграмма развертывания отображает аппаратные элементы компьютера, другие устройства и программные компоненты, а также процессы и объекты, которые им назначены.

* Композиционная структурная диаграмма (Composite Structure Diagram). Композиционная структурная диаграмма — диаграмма, выражающая внутреннюю структуру классификатора. Она показывает его точки зрения взаимодействия с другими частями системы.

1.3 BPWin

На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEFO.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

* контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

* диаграммы декомпозиции;

* диаграммы дерева узлов;

* диаграммы только для экспозиции (FEO).

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

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

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

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

Существуют следующие версии платформы:

· Учебная — допускает конфигурирование, содержит три (?) «компоненты», имеет весьма существенные ограничения.

· Базовая — допускает использование только Базовых конфигураций, не допускает конфигурирования, не допускает смешивания «компонент».

· Стандартная — только «Бухгалтерский учёт», допускает конфигурирование, имеет ограничения.

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

· Сетевая — совместное использование в локальной сети с ограничением числа пользователей или без ограничений.

· SQL — обладает максимальными возможностями, допускает хранение данных в MS SQL Server v.6, v.7 или 2000. Также существуют неофициальные патчи bkend. dll, позволяющие использовать MS SQL 2005 и 2008(с созданием представления для базы данных через SQL Server Management Studio для последнего).

· Может работать в нескольких режимах:

· 1С: Предприятие — основной режим работы пользователя, ввод данных, получение отчётов.

· Конфигуратор — режим администрирования и изменения конфигурации.

· Отладчик — режим отладки и замера производительности конфигурации.

· Монитор — режим просмотра активных пользователей и журнала регистрации событий.

В версии 8 существует 2 основных режима:

1.Режим Предприятия;

2.Режим Конфигуратора (в этом режиме также имеется режим отладки).

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

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

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

Глава 2. Практическая часть

2.1 Star UML

В данном курсовом проекте рассматриваются только Диаграмма прецедентов (Use case diagram) (рис. 1), Диаграмма последовательности (Sequence Diagram)(рис. 2), Диаграмма коллаборации (Collaboration Diagram)(рис. 3) и Диаграмма классов (Сlass diagram)(рис. 4).

Рассмотрим каждую по отдельности.

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

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

Рис. 2. Диаграмма последовательности.

Затем создается диаграмма коллаборации. Диаграмма показывает взаимодействия всех актеров, (рис.3).

Рис. 3. Диаграмма коллаборации.

Диаграмма классов отображает пакеты данных. Если классом руководит человек, то пограничным объектом будет, скорее всего: окно, экран, диалоговое окно или меню. Исполнитель не человек обычно взаимодействует с такими пограничными объектами как программные интерфейсы приложений. Пограничные объекты соответствуют Ю.

Boundary

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

entity

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

control

Все типы диаграмм можно увидеть на рис. 4. Сотрудники это класс entity. База данных — класс control. Система отображения — Boundary.

Рис. 4. Диаграмма классов.

2.2 BPWin

Рисунок 5 показывает контекстную диаграмму, а последующие декомпозицию (рис. 6, 7,8).

Рис. 5. Контекстная диаграмма.

Рис. 6. Декомпозиция контекстной диаграммы.

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

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

Глава 3. Разработка информационной системы в 1С

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

Таблица 1. Структура справочника «Клиенты»

После заполнения справочник «Клиенты» должен выглядеть так (рис. 8):

Рис. 8. Справочник «Клиенты»

Аналогичным образом создается справочник «Сотрудники» с данными:

Таблица 2. Структура справочника «Сотрудники»

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

Рис. 9. Справочник «Сотрудники»

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

Таблица 3. Структура справочника «Номенклатура»

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

Рис. 10. Иерархический справочник «Номенклатура»

Далее создается справочник «Склады», который будет включать в себя один предопределенный элемент — склад Основной, на который будут поступать все материалы. Структура данного справочника:

Таблица 4. Структура справочника «Склады»

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

Рис. 11 Справочник «Склад»

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

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

Документ «Приходная накладная» будет иметь следующую структуру:

Таблица 5. Структура документа «Приходная накладная»

После добавления элементов документ «Приходная накладная» будет выглядеть следующим образом (рис 12,13):

Рис. 12 Документ «ПриходнаяНакладная»

Рис. 13 Печатная форма документа «Приходная накладная»

Далее создается документ «ОказаниеУслуг» и его печатная форма с данными:

Документ «Оказание услуги» будет иметь следующую структуру:

Таблица 6. Структура документа «Оказание услуги»

После добавления элементов документ «Оказание услуг» будет выглядеть следующим образом (рис. 14,15):

Рис. 14. документ «Оказание услуг»

Рис. 15. Печатная форма документа «Оказание услуг»

3.2 Создание регистров накопления и регистров сведений Регистры накопления предназначены для накопления информации в удобном для последующего анализа виде. В данном курсовом проекте представлены регистр накопления «ОстаткиМатериалов» и регистр сведений «Цены» :

Таблица 7. Структура регистра накопления «Остатки материалов»

После проводки документов «Приходная накладная» и «Оказания услуги» регистр накопления «Остатки товаров» будет выглядеть следующим образом (рис 16):

Рис. 16. Регистр накопления «Остатки материалов»

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

Рис. 17. Регистр сведений «Цены»

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

В данном курсовом проекте представлен отчет «Материалы». Он показывает приход и расход материалов на предприятии. структура выглядит следующим образом:

Таблица 9. Структура отчета «Материалы»

И при отладке в 1С Предприятие отчет «Материалы» выглядит следующим образом (рис.18):

Рис. 18. Отчет «Материалы»

Заключение

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

— проанализирована предметная область;

— спроектированы бизнес-процессы и построены контекстные диаграммы, используя BPWin и StarUML;

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

1. Габец, А. П. Реализация прикладных задач в системе «1С:Предприятие 8.2» (+CD)/ А.П. Габец- 2-е изд. — СПб.: Питер, 2007. — 416 с.

2. Гончаров Д. И., Хрусталева Е. Ю. Решение специальных прикладных задач в «1С:Предприятии 8.2». Серия «1С:Профессиональная разработка» — M.: Издательство «1С-Паблишинг»

3. Маклаков, С.В. Bpwin и Erwin. Case-средства разработки информационных систем? М.: ДИАЛОГ-МЭФИ, 2007.

4. Радченко, М.Г. 1С: Предприятие 8.2. Практическое пособие разработчика. Примеры и типовые приемы / М. Г. Радченко, Е. Ю. Хрусталева — М.: КУДИЦ-ПРЕСС, 2010. — 464 с.

5. Чистов Д. Программа 1С: Предприятие и ее базовые модули. — М.: Информ-пресс, 2006.

6. Шмуллер, Д. Освой самостоятельно UML за 24 часа — М.: Издательский дом ''Вильямс'', 2002.-352с.